DATA CHIP 


The Newsletter of the Compucolor Users’ Group 
Of Rochester, New York Our 3rd Year 


Welcome to the fourth year of DATACHIP. We're still going strong. 
We've expanded over the past years from our original 15 or so, to 
the present membership of over 100. Members live in 22 of our 50 
states, several foreign countries, and even ships at sea. Our 
library has expanded from 2 programs to over 45 disks, several 
books and manuals. Meetings have been held regularly on the 
second Wednesday of each month for 3 years now. (That's at least 
30 meetings.) With your support and help, we'll make it through 
the next 3 years as smoothly. Next month, we'll again call for 
dues (still $10.), so get your checkbooks ready. 


Beginning in 1982, your editor will have some help with the 
publication chores of DATACHIP. One of the reasons that it's late 
is that when faced with the onerous task of collating, folding, 
stapling, stamping, and mailing, he slips away down into the 
basement to write some program or other, or slap together some 
hardware. With help to do these tasks (not unwilling children 
pressed into reluctant service), publication will be more 
regular. Advance thanks to Gene Bailey, Don Reinfeld, and Doug 
VanPutte. . 


Our fourth year also starts us off with a new language for 
Compucolors, FORTH. The club's most prolific author, Dr. Jim 
Minor, spent a lot of time in November and December to bring up 
FIG FORTH's version of FORTH and document it. FORTH, in case you 
don't know, is a very fast interpreted language. Based on a stack 
architecture and using "threaded lists", it is a very powerful 
and flexible (extensible is the word they use) language. Jim's 
translation to CCII's is in our library, along with extensive 
(75+pages) of implementation documentation. Jim cautions that the 
documentation he's put together doesn't help you understand 
FORTH, for that you need another text. He recommends Starting 
FORTH by J. Brodie (available in Roch. at Microage store). Send 
$8 to the librarian for the disk and shipping, and be prepared to 
copy and return the implementation manual. (Overseas, add $10. 
for postage.) 


Editor Librarian Subscriptions 

Ben Barlow Dave Suits Gene Bailey 

161 Brookside Dr. General Studies 28 Dogwood Glen 
Rochester, NY 14618 RI. T. Rochester, NY 14625 


Rochester, NY 14623 


Tos COMFPUCOLOR Users Grourr Rochester NY 
Fromi Gon Reinfeld 
Res Furtner FORTH 


Since Gene Bsiley volunteered me to hele rublish this 
newsletters I’ve decided to take my Keyboard in hand «oo 
for better or worse! Ferhaes it is truer after ally that 
Lone more of us nave a nend in eroducings LATA CHIF > 
tne more of us will become more thoroughly ensasésy 
SS the Frencn sau. 


If you misseo the meetins on December 9» you missed 
Jim Minor’s surero demo of his Progress in adarting 
FIG-FORTH for the CCII. 


I learned from Larry Forsley of tne UR Laser Lab - 
“that toe FORTH TUTORIAL MANUAL ¢ A coFY was Fassed ground 
at the flec.? meeting »? is no lonser availsole. He. 
-Pecommended Leo Bronie’s STARTING FORTH, Frentice Halls 
L781» 85 fer surerior. It’s available at the UR Bookstore 
on séle for the course Urtics 246 for $15.95 ( fseerback 3}. 
I’ve resa the first tew charters and find it excellent. 


The Ausust ‘60 issue of BYTE contsins over 40 Frases 
oT articles on FORTH. I hsve this materisl coried and 
can make 1t svailsole to the srour if reorle are 
interested. = 

A software racksse called FORTH FOR COMFPUCOLOR is 
a@lresdy svailaole from an outfit in Ottawa. I was told 
by Nen Urford of COLGRWARE that ne’d be harry to send the 
eOt+ Fase documentation manual for nis FORTH system 
for #6. wnich can be grelied toward the erice of the 
Froasrsms snould one caecide to purchase it later. 
CCULORWAREs F.U.80K 6733» Station J» Ottswar Ontsrio 
NEA Sl4e CANADA} 


Lest May Lnere wes srrarently ¢ st that time I 
maan’t sn inkling whnst FORTH misnt be » & FORTH Standards 
Conterence nela at UR there will be snother this spring. 
4& BOOK Summarizins the conference has Just been rublished? 
THE 1981 ROCHESTER FORTH STANDARDS CONFERENCEs Mt. View 
Fresse 135 Weverls Flaces Mt. Views CA. rrice $25. 
Tnes offer volume Giscounts ¢( 10 cories 43 on this book 
ana STARTING FORTH. Ferrers and caiscussions seem to 
focus on the strensthsr weaknesses, and rossibilities 
sussested by FORTH-79,s the letest standard, 


a Dion Reinfeld 
yea sO Oakdale Drive 
ea Rochesters NY 14618 
, (716-244-3426 


COMPUCOLOR —- If 
ADVANCED PROGRAMMERS MANUAL 


Do you want to know how to use the File Control System in 
your BASIC or Assembler programs? I don’t mean the simple things 
like ‘DIR’ or ‘RUN’. Try the more advanced functions such as 
changing the 1/0 flags, creating new files on the disk or even 
scanning a string of characters for the next non-space character. 
Here is a manual which will help you gain access to the disk 
file manager, the general purpose utility routines and the 1/0 
flags. 


One chapter discusses the general purpose utilities. These 
are the ones which perform the arithmetic, logical, conversion 
and system communication functions. Another chapter covers the 
file manager. You will learn how to create new files, add to 
Old files or read old files. In addition, you can have tectal 
control over random files and the memory image files. The last 
chapter details the mysterious I/0 flags. These flags control 
all character sources in the computer. Now find out what ISC 
never told you about your machine. If you still want more 
information, send an addressed envelope (with postage for 2 az) 
for a table of contents and sample page from each chapter. 


Send: $15.00 ¢US funds) shipping included. 


To: Dale Dewey 
D2 ENGINEERING 
- 7284 High View Trail 
Victor, New York 14564 


Classified Ads. 


HALF PRICE SALE: 32K Compucolor II V8.79 with 117 key 
keyboard, lower case, Centronics 779-2 printer with 
lower case and Compucolor interface/cable, Novation 

CAT modem with cable, nine purchased software diskettes, 
25 additional diskettes, programming manual. $2200. 

Don Miller, 112 Marble Drive, Rochester, NY 14615 
716-663-1175 


16K Compucolor with 117 key keyboard and software. Brand 
new! John Poremba,7 So. Pierson Rd., Maplewood, NJ 07040 
201-762-0585 


Assembly language patch for adding lower case (by color) 
to Text Editor program. $25. Includes print driver program 
to print multiple copies of Text Fditor files. 

Alexander V. Pinter, PO Box 230, Columbus, GA 31902 
404-323-1425 


Sss=SssSsSsSSS==SS== {LOPErISnt LYELL oy J-U.Minor ) 


FCS Read/Write Commands 


This article will be s little different from previous articles in 

thst it will not concentrate on the CC II’s BASIC but rsther on 

“its FCS (File Control System). In my orinions sections of cherter 

10 ¢"FCS") in the "PROGRAMMING AND REFERENCE MANUAL” (1978 Rev 2) 
"ares at besty crurtic. In particulars the instructions for the use 

-af the commands LOAD» READs SAVE» and WRITE ere rarticularly confusing. 
It is my hore that this article will arts the use of these four 
commends. 


NOTATION: I shall use the engdle brackets (*<" and ">" ) to indicste 
optional command rarameterss e.d- . 23 


LOAD <Device Nemei> File Sree <Load Address> —- a, Sg ay - 


-indicates that with the LOAD comand "Device Neme” and "Load Address” - 
-gre ortional. Nested brackets sre always right dustified es in : 


LOAD <Device Nsemet> File Srec <Lowest Address <Memors Srect >, 


Here "Lowest Address” snd "Memory Srec" are both ortionsls however 
-"Lewest Address" must be rresent if we sre going to dive 3 "Memory 
Srec" since the FCS will interrret the first information (if ans) 
after "File Srec” ss "Lowest Address”. ; 


All: address snd srecificstions must be in hexsdecimsl (sorry sbaut - 
that! ). I shall slso use the words "desta" end “information” to 
indicate sny string of information wheter it rerresents numbers, 
alehanumeric strings» BASIC rrogramss machine lsnsusse rrosraems 

or whetever. 


READ and WRITE 


There are seversl "leveis"” of methods in which one can sccess 
information on 32 disk file. The most rrimitive method is to have 
the users write ALL their code from “scratch” in machine lsnsgusse, 
The nexts less primitives method is to use FCS machine lsnsusse 
Programs instslled in the FCS Read Only Memory (ROM) thst comes 
With every COMPUCOLOR. Prosrsems such aes GTBYT snd PTRYT will secess 
3 single byte while others such es RELK snd WELK will sccess 83 whole 
block. These Frosrams ere described by Dele Dewes in his "COMFUCOLOR 
TI ADVANCED PROGRAMMERS MANUAL". 


The nexts more sorhisticateds method is through the FCS Keyboard 
commands, READ and WRITE. These commands ere directly accessible 
throush the Keyboard or may be imbedded in BASIC statements (see 
"Using the File Control System Throush BASIC" in the PROGRAMMING 

AND REFERENCE MANUAL: rase 55). The genersl formst for these commands 
is 


READ <Device Nemet> Stert Block Memory Srec 


and WRITE <Ievice Namet> Start Block Memory Srec 


Definitions? \ 


Bevice Nseme - : 5 
The disk drive thst is to be used. Either the built- 
in drive in which case you may use "CHOt”" or simris 
"O3"» or an external drive (if rresent) in which 
case you could use "Cit" or "1:3". If this commana 
rPsrameter is not rresent then the default drive 
will be used. The defsult drive is CIO on Frowerur. 
ang will remain so unless changed through an FCS 
DEVICE command. 


Start Block - 
Ans one of the 400 (decimal) disk block numbers 
from 0 to 18F (Hex) 


Sate Srec - 
This refers to your Comrucclor’s Rendoe, Access Memory 
(RAM) and can be given in either of two forms. 


1. XXXX ZZZZ . Here XXXX is the starting address 

in RAM and ZZZZ is the total lensth (in bytes) of 

the memory to be used. You may use 3s comms between 
the address in this format if you wishr e@.S. XXXXsZZzzZ 


2. XXXX-ZZZZ . Heres as before: XXXX is the starting 
adress in RAM but the "-" should be read ss "throush” 
ZZZZ since ZZZZ is the last address of the memory 
range to be used. 


Note thet in both cases the memory srec not only 
defines the RAM srace but siso defines sn identical 
Cin # bytes) srace on the disk (starting with the 
first byte in "Start Block") since REAL end WRITE 
commands creste identical cories of the resrective 
informations as we shall see, 


A READ command simrly takes date from the disk and ruts it in memors. 
Thusys either 


READ 2E A000 100 
ors equivelentlys READ 2E AQ000-ADFF 
takes 256 bytes (2565 decimal = 100 hex) from disk block 2E (and 2F 
Since there’s only 129 (80 hex) bytes in 8 block) snd cories it 


into RAM starting st address A000. 


A WRITE command does Just the orraosite of 3 READ command. For exanrles 
either 


WRITE 2E A000 100 
ory eauiveslentlys WRITE 2E AQOD-AOFF 
will take the 256 (decimal) bytes starting in location A000 snd 


cory them into disk block 2E (first 128 bytes) and 2F (2nd 129 betes), 
The dats in memors will not be sltered. 


* 


A word of caution is in order here in that every time informstian 


is written to s disk blocks 3 CRC word is senersted and rlaced in 

a formatted srace cutside the 128 byte information resion in thast 

disk block. Thuss if you WRITE 60 bytes to s Block but subseauentiy 

READ backs says 40 bytes then you will encounter en ECS error 

(BDsats CRC error) since your newly-senersted READ CRC value will 

be different from the imbedded (on the disk) WRITE CRC value (unless 

rerhars the 20 bute difference consisted of all zeros). A goad 

rule to follow is to make sure that sou don’t try to READ beck 

anything more GR less than you read into 3 block. However: for 

unusual circumstances it is worth noting that even after a READ 

followed by an EDCS: the information hes been reed into memory (the 
read date CRC Just didn’t eaual the "block" CRC value). 


Both READ and Write do not make use of the disk directory and so 
care should be exercised when using these commends as the directory - 
will not be updated with s WRITE command nor will it be consulted 

to make sure you’re getting the correct information in s REAL. 


SAVE and LOAD 


These two commands are the most "sorhisticated" in that they not 
only sccess information on. the disk but thes work throush the disk 
directory and therefore you do not need to srecify disk blocks but 
rather you can desl with the more convenient disk "File Srecs” 
(the directory will be used sutomatically to comrute the relevant 
blocks). : 


SAVE $ 


The SAVE command hes the general form? 


SAVE <Tevice Nemet> File Srec Memory Srec «Start Address “Actusl Address:> 


(ce ee ee ce ce ae ee ee ee me ee ee ees ee ee he ee me cee ee ee ee ee 


1. CRC - Cyclic Redundancy Check. Similer in intent but more Fowerful 
than 3 rarity or checksum oreration. As data bytes sre written 

to a disks in 8 Parallel activity the deste is also “scrambled” tosether 
to form two bytes (the CRC word) which is characteristic for that 
string of information Conls one chance in 65535 of making 3 REAT 

or WRITE error and not detecting it! ). This word is stored slons 

with the written informstion (but in 3 non information resion of 

that block) so that when this information is subseauentliy REAT the 
information can be rerrocessed to see if the new CRC is eausl to 

the "old" CRC and therebs verify that the information was rrorerly 
transferred, 


Definitions? 


Bevice Neme - 
Ssme ses before. 


File Srec - 
Describe how you want the file listed in the directors, 
The general form is 


File Name <.File Tyre <sFile Version: 
File Name. 1-6 alrehanumeric characters of your choice, 


File Tyre. 1-3 elrhsnumeric characters of your choice 

but be aware that certsin tyres have special interrretations 
when used with other commands and rrosrams. The 

default ture is .PRG . 


File Version. A hex number from 1 to FF. Your 
choice but you’ll set an ELFN (durlicsate file) error 
if the version of that file slresdy exists. In my 
oriniony it’s usually best not to srecify this. 

The default value is 1 if no file of this neme and 
ture presently exist in the directorys otherwise it 
is one greater than the highest version number of 
thet file reresently existing. 


Memory Srec - 
Same as before. Hoth formats rreviously defined 
are accertable. The first number slways becomes 
LAUR <(Load Address) in the directory. If an "Actual 
Aderess" is givens then the meanings of the first 
"Memory Srec"” number is slitered. See below. 


Stert Address - 
& RAM sddress. If surrlied by you in this commend 
this address will be inserted as SARBR in the disk 
Girectors. LTefsult value = LAIR. 


Actual Address —- 
& RAM address. If surrlied by sou this indicstes 
that the dats to be saved is not Fresently st "Memors 
Srec” but rather at "Actusl Address” end the commens 
will execute as follows? 
1. The number of bytes to be saved will be obtsined 
from "Memory Srec". i 
2. This number of bytes will be obtsined seauentisalls 
starting at "Actusl Address”. 
3. LADR will still be comruted from the first number 
in "Memory Srec". 


For examples 


SAVE TEST.ABC 7000 1000 70035 ADDD 


ory eauivelentis:s SAVE TEST ABC FO00-9FFF 9003 A000 


will save (on the disk) 1000 (hex) bytes rresently stored seauentisllis 
in memory starting sat A000. The dats will be stored in the next 
avesilable free srsce on the disk end the directory will be urdsted 

by aessisning the File Srec TEST.ABC#01 to this date (sssuming no 
other TEST.ABC exists on the disk) sand will give location and size 
information as well as sssisn 3 load address (LAIR) of 9000 snd s 
start address (SAIIR) of 9003. The data in RAM will not be sltered, 
The imrportsnce of LAIR snd SADR will be discussed lester, 


As another exsmrles consider 


SAVE QUICK KO000 200 
ory equivalently, SAVE QUICK BOOO-BIFF 


which will save 200 bytes in the next availseble free srace on the 
gisk and the directors will now contain 3 File Srec of QUICK.PRGsO1 
with LAIR of BOOO and a SADR of BOOO, 


LOAI - Case 1. File tyre is NOT .LIAS 
If the srecified File Tyre is eny tyre other than .LIKA then the 
command is relstivels simrle - 


LOAD <Llevice Namet> File Srec <Losd Address> . 


Ttefinitions? 


Device Name - 
Ssme as before, 


File Srec - ; 
Same as before excert now the file must be listed 
in the directory. The defsult value of the File 
Tyre is .LDUA so for Case i it must be srecified 
(as some other File Tyre). -If no File Version is 
sivensy the highest version listed in the directory 
will be used. 


Load Address - 
The (RAM) address at which the first bute in the 
first disk block is to be loaded. Theresfter the 
remaining bytes will be written in 2 seauentisl 
fashion into RAM until the file is exhsusted. The 
disk contents sere unsltered. The defsult velue 
is the LAIR vselue siven for that file in the directors. 


For exemrles usins our previously SAVEd files 
LOAD QUICK.PRG 


will cory the 200 bytes of QUICK.PRG starting at RAM address BOO0O0 
(the file’s LAIR es given in the directory when the file was SAVEd). 


LOAD - Case 2, File Tyre is .LIA? 

If the srecified file is of file aoe +LitAs then the senersl format 
of the LOAI command can be different than thet given for Case il, 

In order to srrreciste the need for this difference it is helrful 
to examine the structure of a .LIA file. 


411 the orerstions we have considered so far have consisted of transcribing 
3 series of deste bytes (datear texts rerosramss etc.) from disk toa 

memory or vice verss in s CONTIGUOUS fashion with sbsolutely NO 
INTERPRETATION of the bytes by the trenscribing rrocess (other than 
@rossible CRC orerstion). An .LUA filers on the other hand has slightly 
more "structure" than merely beings s string of betes snd demands 

more of the loadings oreration. 


Aan .LUA file is broken into contiguous segments called "data records”. 
A date record consists of 3 four byte header and then the body of 

the record. The first two bytes of the header sive the length of 
‘the dats record (low bste first) exclusive of those first two bytes, 
There erresars to be 3 limit es to the length of se dstea record in 

that I have not seen one that was more then 80 hex bytes lons (I 
haven’t tested to see what would herren if I constructed es longer 

one thoush). Thus it is common to find headers that start with 

"7JE 00” (126 decimal bytes + the first two header bytes = 128 decimal 
or 80 hex). Hytes number 3 and 4 in the header give the load address 
“of that date record. Thus 3 date record that starts out with 


7E 00 00 82 


sausy "load the next 124 (decimal) bytes (128 byte dete record minus 
4 byte header = 124 byte body) into memory starting at locstion 3200", 


Excerpt for the last dats records a date record can be ss short ss 
Sbutes (4 byte headers 1 byte body) end in 3 multirle record file 
(most files are multirle record) one dats record follows sanother 

in 8 contisuous fashion and so can "sran” 3 disk block (i.e. start 
in one disk block sand continue into and end in the next). The lest 
gates record is srecisl in that it sives the starting (execution) 
address for this files essumins this is e machine lsnsuese frosream. 
The form of the last record is simrls 


02 00 "LOW" "HIGH" 


where "HIGH" and "LOW" ere the hish- end low- order bytes of the 
Program starting address. 


The frimary source of an .LIA file is the COMPUCOLOR Assembler frosrem 
{not the MACRO Assembler) and for vou assembly lansuase Programmers 

the file consists of sour Frosrem’s machine code targeted by the dsts 
record formst to its srrrorpriste elsce in memory. Your GREG ststement 
sets ur the first date record tarset address (i.e. header butes 3 sand 4) 
and will continue to bresk the code ur into 124 byte "chunks" until 
another assembler directive (e.g. another ORG or s BS which is s 
Girective to "SKkir” so many RAM bstes) tells it to end thst dats record 
and then in the next header srecifies the new tarset sddress. The 

last dete record in that file is crested with your END statement. 


If your rrosram has bits end rieces of code and dats all over the 
memory marr this format provides 8s very comrpsct ways of storing it. 
If however» sour Frosram is relstivley contiguous in memorss then 
it will load faster in the future if you first LOAD it as sn .LIA 
files imneiubbetion its range in memorys snd then save it as s .PRG file. 


Before getting into the rarticulars of the LOAItins of san .LBA files 
it should be noted that the directory’s LAIR and SADR values ere 
not used in the execution of this command. Indeeds the .LIA file 
crested from COMPUCOLOR’s Assembler Frosram slwass hes LAIR = SADR 
= 8200, resardless of the ORG or END statements’ addresses, 


The simrlest form of using the LOAD command with an .LIA file has 
the form 


LOA <Ilevice Namet> File Srec 


where ».LIA in the File Srec is ortionsl since it is the default ture, 
This command simply targets or "vectors" the date records to their — 
aprrorpriate memory regions, as given in each record header. This 

is @ very straishtforward oreration and I see no reason why other 
Programs (machine lsnguase and otherwise) could not be written to 
take advantage of this uniaue memory "vectoring” carsbility, 


However» the command hes 3 more general forms obtained by includins 
optional parameters. To mys rather unimadinatives mind the ceases 

where one misht went to use this extras "firerower”" are rather ratho- 
losdical. Nevertheless, I shall detail them for the sake of comrleteness, 


The general form for LOALIting an .LIA file is 
LOA <Iievice Namet> File Srec “Lowest Address “Memory Srech> . 


Rather then Just List the definitions for the new Fersameters: "Lowest 
Address” and "Memory Srec"s I shall try to exrelain their oreration 
in context. 


The "Memory Srec” can have either of the formats defined before 

PLUS 3 sinsgle-number format. The srec defines sn sbsolute RAM range 
(termed "memory range") where you will allow the file to be written, 
Any byte thet sets vectored outside this range will be isnored and 
no error messese will be written. Thus this serves to "rFrotect” 
memory information outside the rense end avoids trying to write 
"extraneous" dats records in 3s file. If se "Lowest Address” is sSiven 
and no "Memory Srec"s then the defsult value is ADOO-FFFF. On the 
other hand» if 2 "Lowest Address” is given and only one number is 
specified for the "Memory Srec"s that number is taken es the low 
limit of the memory range with the hish limit defsulted to FFFF,. 
When used in thisways, the LOAD command rerresents the only FCS 
command that I Know of where you misht be sble to selects resd and 
Simultsneously store 3s single bytes other then the firsts from 3 
file. 


The "Lowest Address” rsrsmeter iss to mer even more srcene. If you 
wish to shift ("offset") the date record information XX bytes UF 

from its “tarset” es siven in the headers then you srecify s "Lowest 
Address” XX bytes HELOW the low limit of your "Memory Srec”. Toa 

see these rarsmeters in actions consider 3 dats record in file TEST.LIA 
with hesder 


62 900 00 35 
which seus there is 0062 - 2 = 60 hex butes of information in that 


records "vectored" to RAM location 8500, If this file is losded 
with 


LOAD TEST 8400 8400-8740 


then this will losd the dets record into RAM starting st locstion 
8500 + (8600 - 8400 ) = 8700 and run through 8740 (the end of the 
memory range). Thuss the first 41 hex bytes will be losded but the 
remaining 1F bytes of that record will not. If you Just want to 
Provide 3s memory range (with "Memory Srec”) but not csuse the dats 
record to be offsets simply make the "Lowest Address” eausal to the 
low limit of the "Memory Srec", e.g, 


LOAD TEST 8400 9400-8600 


will write our data record into 8500 (its orisinsl tarset) ands sas - 
we’ve srecified it heres the comrlete record will be written since 
it all falls within the memory ranse. 


RUN 


The RUN command is vers Simrle. It has the form 
RUN <Device Nsemet File Srec * 


The file in “File Srec” must have 3s File Tyre of either .PRG or .LIA 
with .PRG as the defsult tyre. If the file is of tyre .FPRG then 

it will be loaded at the LAIR es siven in the directory snd it will 
stert executing at the SADR. If the file is of ture .LItAy then 

it will be losded as 2 collection of date records es in s LOALs 

Case 2 and will start execution as directed by the last date record. 


THE VERY SIXTH LIBRARIAN'S REPORT 


Have you been counting? FORTY-FIVE disks! Not bad for a motley crew 
of hobbyists doing work on an extinct machine. We've received some new 
educational software, a prize of programs from Don Miller, and the 
Australian group sent up quite a few terrific programs. You can contact 
their very active group through Greg Hubbard, 9/43 Kensington Road, South 
Yarra, Victoria, Australia, 3141. : 

And there's more to come. Stay tuned. Keep at it. 


NEW LIBRARY DISKS 
(January, 1982) 


DISK 39 Business 
STOCK PRICE DATA, by J. R. Thirtle. 
PORTFOLIO RECORD, by J. R. Thirtle. 
CONDO, from Softswap. Computes cash flow and net profit for an 
investment in a condominium. 
HOUSE, from Softswap. Computes actual cost of a house, given purchase 
price, amount borrowed, interest rate and monthly payments. 


DISK 40 Games 

FOOTBALL, by R.B. Holley. Different from PRO FOOTBALL on Disk #15. 

MAZE. Draws a large maze on your screen. Good luck. 

NUCLEAR POWER PLANT, by D. Niven. Try to provide power and avoid a 
meltdown. 

CRAZY 8, by B. Muldowney. The card game. 

BACKGAMMON, by M. Alan. It's you against the computer. (Not the same 
Backgammon program as on Disk #5.) 

KIWI, by D. Niven. A board game where you must find the KIWIS to save 
them from extinction. 


DISK 41 Games 

SIMON SAYS. The color/tone matching game. Uses Soundware and expects 
the extended keyboard with the color keypad, although the BASIC 
program could be easily modified. 

MINE FIELD, by D. Niven. Try to pick your way across a mine field. 

FOUR. A game of strategy against the computer. Something like 
tic-tac-toe, but with an interesting difference. 

SANTA PARAVIA & HAWTHORNIA, by K. Ochiltree. A Hammurabi-like game. 
Requires 32K (!). 

CHOMP. Up to ten players chomp on a poison cookie. 

HUNT THE SNARK, by L. Ferguson. A board game for one player. 

HEXPAWN. A simple board game, you against the computer. It is 
interesting to see the computer learn from its mistakes. 

BINGO. For one or two players against the computer. (Not the same 
BINGO as on Disk #3.) 


DISK 42 Utilities 

RANDOM FILE SORTING ROUTINE. Sorts up to 1000 numeric or character 
items. Uses two disk drives for very large files. 

EASY MENU. A BASIC program which prints the disk directory and then, 
with single key strokes, allows you to load a file, load and run 
a file, change default device, copy a file, or delete a file. 

ASCII DUMP. Dump disk files to screen in ASCII. 

INDEX, by G. Hubbard. A disk catalog system using random files. 

BASTED, a source file generator, by B. Muldowney. This is an ingenious 
program which generates an ASCII text file (for letters, assembly 
language, etc.). You write your text in a BASIC program using only 
REMark statements. Then give it to BASTED to convert to straight 
text. : 

SCREEN DUMP, by P. Stuckey. Screen display dump to Microline printers. 
Handles both text and graphics. : 


DISK 43 Scientific & Engineering 

Reactance of Inductor in Ohms. Network to Match RF Output to Load. 
Capacitor for Known Ripple Volts. Capacity Required for Desired 
Reactance at a Given Frequency. L-Pad Attenuator for Lowest Loss. 
Find Inductance, Capacity, Frequency. PI or T Resistive Attenuators 
(non-symmetrical). Symmetrical Attenuators. Reactance of Capacitor 
in Ohms. Find Ripple Volts Given Current and Capacity. Winding 
Data, Ferrite Cores, Using AL Values. Circuit for Variable 
Regulator 317/377. 


DISK 44 Games (from Don Miller) 
MISSING LINK, the game from Ideal Co. 
RUBIK'S CUBE. Requires 32K. 

O'NO 99. Card game. Requires 32K. 


DISK 45 Games 
_ PRESS UPS. Board game for one or two players. 
REACTION TIME. How fast are you? Uses Soundware. 
SOLITAIRE POKER. 
FLEXIBOX. A 'flexible' black box game. (See BLACK BOX on Disk #16.) 


Library information: 
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an be ordered from =he librarian 5y mumoer. Datachis paericdically 

a cataleg sf all Library disks. We now Mave over TO cisks containing 
s for games. education, Business, Languages, and cther. We Rave anc 
ms which are sold Sy Compucclor or its dealers (MTRIP). 


When erdering, include either $5 per disk desired. or send your cwn 
include postage/handling money (adout $.75/disk). Overseas subscribe 
imelude about S$2-t. ger order for postasge/Rancling, or 36. per sis. 


Mote that while we doen*t nave a trace solicy as some clubs sco 
SuSmi2 a crogram tc get a sregram), we strongly ancourace you 
cr two when dealing with the Library. Include alse, if mst on 
imstructions if required, or arcgram/versicon limitations. Your 
Sisk will Se rsturnmed to you (we say). 


Mur librarian’s mame and address: David &. Suits/General Studies/R.I.T./ 
Rechester, NY/14425. 


16K ADD-ON MEMORY 


Make your Model 4 into a Model 5 


If you are tired of seeing the "OM" error message on your 
Model 4, there is a way to solve the problem. You can buy an 
.add-on memory board OWR_ you can build one fog yourself. If 
you buy it, expect to spend about $3525 but you should be able 
to build one for about $75. f 


Here is a tutorial paper on the subject of add-on memory 
for your Model 4. This paper includes a complete explination 
of how the computer decode/refresh ROM keeps the RAM working, 

a circuit diagram for the add-on RAM, wire list, parts list and 
anew address decode/refresh ROM chip (825129). This chip is 
required to give your machine the necessary decode logic that 
makes it into a Model 5. You get to buy the parts, assemble a 
board (with lots of love and care) and install everything in 
your machine. 


Send: $9.50 (US funds) shipping included. 


lower CASE ROM KIT 


ARE YOU TIRED OF UPPER CASE CHARACTERS AND FUNNY @Ge4vno 
CHARACTERS IN YOUR TEXT? HOW ABOUT WHEN YOUR WRITING A LETTER 
AND THE "CAPS LOCK" KEY COMES UNLOCKED? TIRED OF GREEN AND CYAN 
CHARACTERS RATHER THAN REGULAR UPPER AND LOWER CASE CHARACTERS? 


Well here is a new character generator ROM kit which will 
give you lower case characters with the flip of a switch and 
still retain those special characters you need for all of the 
games you have written. The kit includes complete installation 
instructions, a new ROM with socket, a switch and wire. The 
only tools needed are a 1/4 inch drill (hole for switch), a low 
wattage soldering iron and about 30 minutes. 


NOTE: The COMPUCOLOR-II is not capable of mixing 
lower case and special characters on the 
screen. With this kit, you can have one 
or the other but not both. 


Send: $35 (US funds) shipping included. 


Tos Dale Dewey 
D2 ENGINEERING 
7284 High View Trail 
Victor, New York 14564 
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RANDOM THOUGHTS #5 
by 
Rick Taubold 


In my last article I discussed various techniques for speeding 
up program execution. A program can also be improved by making 
it shorter. This frequently speeds up execution while at the same 
time conserves memory. So, my title this time is-- 


"The Big Squeeze" 


Before my readers accuse me of being a fanatic on the subject 
of program efficiency, I would like to point out that I am not 
especially concerned with short to moderate length programs that .- 
do their job well. If you have a nice 10K game or whatever that 
only takes a second or two to made a decision and return to the 
user, that's fine. In that case your logic and algorithm may 
not need to be improved. After all, if a program decision takes 
a half a second and changing the algorithm will double the speed, 
who is going to notice the difference? 

What does concern me are those over-16K-programs which should 
be runnable in a 16K machine, and those programs that keep you 
waiting forever before you can enter your next move. I am not. 
referring just to games. The computer is supposed to make life 
easier,not waste your time. Let's look at the pocket programmable 
calculators for an example. Have you any idea how long it takes 
to generate 5 random numbers to simulate 5 rolls of the dice on 
one of those things? It takes at least 10 to 20 seconds! You 
could do it by hand and write down the results in half the time. 
The computer gains us nothing, rather it wastes our time. 

My recent program "Castle Quest" is a prime example of a 
too-long program. I originally conceived of it to run in well under 
16K. Needless to say, it quickly outgrew that goal and wound up 
a huge 20K+. It was obvious that users with 16K machines would not 
be able to appreciate my efforts. So, I sat down to work. What 
I discovered and learned form the basis of this article. By the 
way, the end result of my programming efforts was a 16K version 
without any loss of functions whatever. In fact, I enhanced the 
larger version slightly to add another difficulty level. Only the 
very brave have attempted it. 


In the July, 1981 issue of Creative Computing, page 78,was 
an article entitled "RAM Cram Techniques for Atari." I began with 
this, seeking to discover how much of it applied to the CCII. 
The first thing to go were the REM statements. There I saved about 
1000 bytes. But let me warn you of a potential problem. I REMmed 
all of my subroutines and put my GOSUBs to the REM statement. Of 
course, I did this before I realized I would later need to remove 
them. This caused all sorts of headaches. I had to check all the 
GOSUBs one by one and edit the line numbers in them. My program 
was almost enitrely written with subroutines. It was a lot of 
work. And, I missed a few. Later on bugs would creep up that 
ultimately traced back to my oversights. MORAL: If you do use 
REM statements, either put them at the end of a line or be sure 
your branches are to the line after the REM. 
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I have a word of warning for all programmers. I do not in any 
way condone the omission of REM statements. I have run into too 
many programs with inadequate or no documentation. Users usually 
have no way of using the program. It's a shame, because there are 
a lot of nice programs out there unable to be used because the 
programmer failed at the most important part of his job--DOCUMENT! 
It brings tears to my eyes whenever I think of our nice 32K MONOPOLY 
program that no longer has documentation. There is no record of 
the commands; it will require some time and patience to recover 
them from the program itself. (If anybody out there in the range 
of this article has the commands, please send them to me or to 
Ben Barlow or Dave Suits. It'll save me the time of digging.) 
Here, again, a few simple REM statements would have solved the 
problem. 

Back to my problem--The only reason I eliminated the REMs 
was that my 32K version of ‘Castle Quest‘ did have them and I did 
plan to furnish complete written documentation on the game. You 
know, there is another way to have the best of both worlds. Simply 
write a separate program with instructions and a set of commands. 
The "Airline Flight Simulation" game is a good example. Although, 
the map was missing, the programmer at least gave the original 
article reference. 

There I go, up on the old soapbox again. Back to the discussion. 
The Atari is a Strange machine. It wastes space. Everytime your 
program specifies a constant, be it zero or some large number, the 
machine stores it in a 7-byte section of memory. This means that 
if you write X=%9 ten times at various places in your program, 
each occurrence of that @ will use up 7 bytes--7% bytes in all. " 
Since my program used a lot of @ and 1 values for flags I sought 
to investigate. I had forgotten something I had heard long ago 
about the CCII. Instead I replaced 1's and @'s with a variable. 
When I checked the memory usage, there was no change! I had just 
wasted a half an hour or more. Then I remembered that the CCIIL 
uses up one bytefeor its BASIC token words and 1 byte for every 
other character be it numerals, letters, symbols or control char- 
acters. But it is this difference in the CCII that I put to good 
use. I had used the Scrolling Patch in the program and had placed 
it at line number 60000. Every GOSUB 60000 ( and I have over 50) 
used up 6 bytes altogether. By moving the subroutine to line 
number 60, I eliminated about 150 bytes. And I got a bonus. 
Because the subroutine was not at the start of the program, the 
scrolling was noticeably faster. I saved both space and execution 
time. This was exactly what I wanted all along. 

Along these lines, one can reduce memory usage by shortening 
messages, sometimes drastically. Consider, too, the occurrence of 
redundant messages. Let's say your program has the two messages: 


PRINT "YOU HAVE FAILED TO COMPLETE THE MISSION" 
PRINT "YOU HAVE FAILED TO ESCAPE IN THE TIME ALLOWED" 


What can be done about this? Consider the use of a string variable 
like this: A$="YOU HAVE FAILED TO". Can we not simply write a 
statement: PRINT A$;'" COMPLETE YOUR MISSION" and do likewise for 
the other message’ Granted, we have only saved 15 bytes (18 on the 
message, but subtract 3 for the A, $,and semicolon added.) 
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Nevertheless, if you use a lot of long and redundant messages, 
this trick may save a lot of space. Some game programmers like 
long messages and long games. Be conservative. 

You should also be aware that control characters can eat up 
space. Every time you change color in a PRINT statement with a 
a color key, one byte is used up. When possible use the PRINT 
statement to change color rather than the PLOT statement, if you 
simply want a message to be another color. But it is also up to 
the programmer and the requirements of his program. Just be aware 
of how many bytes you are using in each case. Also, with regard 
to changing color, it is not necessary to use FG ON and the color 
key each time you change color. The color key is enough unless you 
want to change BG color instead. 

Another way to save space, sometimes a lot, is to put some 
of your information in a permanent screen display which can be 
loaded from the disk. If you have a lot of headings, etc., this- 
can help out. But you may also have extra PLOT commands needed to 
put the cursor where it is needed. Use’your judgment. If you 
don't have a screen display, it is probably more wasteful to add 
one. If one of these is already present, consider adding more 
information to it. Look at "Star Trek". The display has a lot 
of printed information besides the graphics. This is the kind 
of thing I'm talking about. 

I already mentioned about moving subroutines to lower line 
numbers, especially if you use them a lot. The same idea applies 
to line numbers in general. If your program has a lot of GOTO 
statements, a simple renumbering of your program will reduce the 
overall size of the line numbers. Consider numbering your 
final program starting at line 10 or 100 and numbering by 5 
rather than 10. If nothing else, the end result, whether numbered 
by 5 or 10, looks a lot neater. It makes you laok better as a 
programmer. 

The placing of multiple statements on a line will save space, 
but it can get messy. I only recommend it when space is a problem. 
In general, one statement per line, or occasionally a couple of 
short statements per line, is best. And watch out for what 
follows an IF statement on a line. I shouldn't have to say this, 
but there are still some (not neceasarily CCII users) who forget 
this. In the line IF X=5 THEN Y=X+4:GOTO 100, remember that the 
GOTO will only execute when the IF statement is TRUE. Beware! 

A few quick space savers--(1) Keep arrays small. Each element 
of a numeric array takes up at least 4 bytes. And remember that 
the zero element is always present. An array DIM X(1@) has 11 not 
10 elements to it. (2) Eliminate unnecessary parentheses by using 
the hierarchy of operations to good advantage when possible. 
(3)Large numbers like 249009 can be replaced by 2245 and save 
you 2 bytes. (4) A lesser known tidbit is that IF X<>@ is the 
same as writing IF X . However, this is only good for numeric 
variables, not strings. This saves 3 bytes. 


I am sure that I have not covered everything. Whatever I have 
overlooked, I would appreciate readers' comments about. If I get 
enough response perhaps I will do a follow-up article in the 
future. But now, I'm sure you are all anxiously awaiting the 
answers to last month's problems. Here they are..... Seales cece car tol od 
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The first problem was to speed up the 'Prime Number Cruncher'. 
By modifying the existing program the best time I got was just 
over a minute. The first modification consists of realizing that 
the inner loop from 2 to 50@ is unnecessarily long. In testing 
for possible divisors of the test number, we realize that the 
largest value needed to be tested is the square root of the 
number. Hence, the inner loop now goes 2 to SQR(N). At the 
last value, 149%, this value is 31.6. That means that here alone 
we have almost 47¢ fewer iterations of the loop! The second 
modification is to eliminate testing certain values which can 
never be primes-—-the even numbers. If the outer loop is stepped by 
2, we remove half the iterations there. Of course, two is a prime, 
but, being the only even prime, we simply add an extra PRINT 
statement at the start of the program to handle 2. Actually, the 
inner loop also need not be stepped by 1; we can also step it by 
2 and start it at 3. Line 24¢ is not needed so delete it. 
This leaves us with the program: 


130 PRINT "STARTING" 190 IF L=1 THEN 22¢ 

140 FOR N=3 TO 194% STEP 2 210 IF M=L THEN 2494 

150 FOR K=3 to SQR(N) STEP 2 220 NEXT K 

160 M=N/K 230 PRINT N; 

170 L=INT(M) 240 NEXT N 

180 IF L=$ THEN 23¢ 260 PRINT "FINISHED" 
270 END 


The run time was 1:18. But there is. a much faster method. 
Rather than give the answers here, I will give you the hint. The 
answer is given next time. Instead of trying to test a number 
for primality by division, generate the non-prime numbers from 
1 to 1000 and print out what's left. As I saidlast time, my best 
time was under 15 seconds. I figure this is about the best time, 
period. It takes about 5 seconds just to print out the results. 
So, this seems to be the limitation. Finally, we have reached 
the machine's limit rather than the programmer's limit. Of course, 
using machine-language to output the results could improve this 
time. But look at what we have accomplished in BASIC! We took 
a 20-minute brute-force program and performed exactly the same 
task in less than 15 seconds! Just the above program did it j 
15 times faster. Let's see what you can do. To sum up, we have 
arrived at the best and most efficient program when we are limited 
only by the hardware. BASIC still limits us, but in this case, 
the limitation is almost trivial. 

The second problem I posed, how to print out the octagon of 
dots, is somewhat simpler. The fastest way is to use PRINT state- 
ments such as PRINT TAB(12)". . « « « «" Teaving two spaces 
between each dot. While fast, it takes up 525 bytes. The other 
method I looked at (and used) takes 3 lines and 13% or so bytes: 


100 FOR L=3 TO 27 STEP 2:READ X,N:FOR K=X TO N STEP 3 

110 PLOT 3,K,L:NEXT K,L 

120 DATA 15,27,12,3¢,9,33,6,36,3,39,3,39,3,39,3,39,3,39,6,36, 
6 45,12, 20 15,27 


It's not as fast, but I felt that it was fast enough for the space 
saving. If you have something better, I would like to hear about 
it. Until next time.... (RICK TAUBOLD, 197 HOLLYBROOK RD., 
ROCHESTER,N.Y. 14623.) : 


COoLoRCUE ge: “sf 
BACK ISSUES 


Back issues of Colorcue are an excellent source of inforsation about Compucolor computers, ISC computers, and progragming 
in general. Interviews, interesting articles, and prograas are all there with a touch of history. 
All of the following are available fro our Rochester Editors: 


MULTI-ISSUES at $3.50 -each: 
—_ Oct, Nov, Dec 1978 

Jan, Feb, Mar 1979 

Apr, May/Jun 1979 

Aug, Sep/Oct 1979 


INDIVIDUAL ISSUES at $1.50 each: 


_. Dec/Jan 1980 __ Feb 19890 _. Mar 1980 

_ Apr 1980 __ May 1989 __ dgun/Jul 1980 
INDIVIDUAL ISSUES at $2.50 each 

— Dec/dan 1981 __ Aug/Sept 1981 _. Oct/Nov 1981 
POSTAGE: 


US - First Class postage included 
Europe, South America -— add $1. per issue for air 
add $ .40 per issue for surface 
Asia, Africa, Middle East - add $1.49 per issue for air 
add $ .60 per issue for surface 
DISCOUNT: 
for orders of 10 or more items, subtract 25% from total after postage 


The list above includes every Colorcue ever published. It it isn’t on the list, there wasn’t one. 
1978 issues are in short supply, so if you’re interested in thea, order now. 


Colorcue 

Editorial Offices 

161 Brookside Dr. 
Rochester, NY 14618 
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